Wer ein neues Framework testen möchte, muss gleich ganz umsteigen, oder? Nein! Mit Vue.js ist es möglich, erst einmal nur einen Teil des Projekts zu migrieren und so herauszufinden, ob man damit arbeiten möchte. Wir haben auf den JS Days 2019 mit Vanessa Böhner über Vue.js und die Migration bestehender Projekte gesprochen. Die Speakerin gibt im Interview Einblick in ihre Erfahrungen und Tipps zum Vorgehen.
Ann-Cathrin Klose: Hallo und herzlich willkommen auf den JavaScript Days 2019 in München. Ich bin Ann-Cathrin Klose und bei mir ist heute Vanessa Böhner. Hallo Vanessa! Wir unterhalten uns jetzt darüber, wie man Vue in Legacy-Projekten einbauen kann. Erstmal ganz grundlegend die Frage: Geht das mit Vue und Legacy-Projekten?
Vanessa Böhner: Auf jeden Fall – hängt vielleicht nicht unbedingt mit Vue per se zusammen, sondern ich würde wirklich sagen, dass man jedes Framework, fast jedes Framework in der Legacy Code Base reinbekommen kann. Da ist vielleicht auch eher die Frage, was ist eine Legacy Code Base? Ich habe mir das auch mal überlegt, was ist das denn eigentlich? Ich bin tatsächlich der Meinung, alles, was ich gestern gemacht habe, ist ab heute eigentlich schon Legacy. Es sind alles nur Programmiersprachen im Frontend. Es ist an sich alles mit JavaScript. Das ist natürlich möglich.
Ann-Cathrin Klose: Bei Vue im Speziellen: Wie sehen denn da deine Erfahrungen aus? Wie gut geeignet ist Vue denn dafür?
Vanessa Böhner: Das Erste, bevor ich es mit Vue gemacht hatte, da habe ich es schon mal bei React gesehen. Da war ich auf einem Meetup, da wurde es mir vorgestellt, wie sie es dort gemacht hatten. Die hatten dort ihre ganze Homepage, und die hatten sich bestimmte Komponenten rausgesucht. Ich glaube, das war auf der Basis wie man es kennt: HTML, JavaScript und JQuery. Und die hatten gesagt: „Okay, wir wollen jetzt mal die Navigationsleiste und den Footer einfach mal ausprobieren, mit Vue umzusetzen, weil wenn der Footer jetzt mal kaputt geht, da ist noch kein Umsatz verloren. Da ist kein Log-in-Button drin, da ist kein Warenkorb-Icon drin, der mich zur Kasse führt, also wenn mal der Footer für einen oder einen halben Tag kaputtgeht auf Production, wäre das jetzt noch nicht so tragisch. Genau das gleiche Format habe ich mir dann auch rausgepickt, als ich versucht habe, bei einer Legacy Code Base Vue.js. einzusetzen. Das wir eben gesagt haben: „Okay, wir picken uns jetzt auch solche einzelnen Komponenten raus und schreiben die einfach mal um, bzw. das waren jetzt gar keine Sachen, die wir umgeschrieben haben, sondern das war ein neues Feature, das wir auf der Seite dann mit rein integrieren wollten. Das konnten wir wirklich relativ einfach machen, dass wir die Vue Single Page Application geschrieben haben (und das war eine ganz, ganz kleine Single Page Application) und wir hatten eine Webseite, wo die Seiten per PHP serverseitig gerendert wurden, und dann haben wir einen leeren DIV-Container eingefügt mit einem bestimmten ID: zum Beispiel featureXY-vue, oder ohne vue, wie man das eben dann handhaben möchte, und das JavaScript von der Vue-Applikation wurde dann nachgeladen – das kam ganz normal mit dem JavaScript Bundle, hat geschaut, ob denn jetzt dieser Container mit dieser ID auf der Seite vorhanden ist, und wenn ja, spiel mir jetzt hier meine Vue-Applikation rein. Und schon war die Vue-Applikation auf der Legacy Code Base – und das war eigentlich innerhalb von eineinhalb Tagen live.
Ann-Cathrin Klose: Also für kleiner Aspekte funktioniert es ganz gut. Gibt es Hürden, auf die man achten muss oder Probleme, die man bedenken muss, wenn man jetzt anfängt, mit Vue in irgendeinem bestehen Projekt?
Vanessa Böhner: Ja, es kommt natürlich total darauf an, was man denn jetzt eigentlich vorhat. Möchte man das erstmal ausprobieren, möchte man komplett alles migrieren damit, oder sagt man: „Nee wir wollen jetzt nur die neuen Features damit umschreiben, weil wir da bei der Entwicklung schneller sind“? Je nachdem sollte man vorher abwägen, wie man das Ganze macht. Hat man wirklich vor, die komplette Code Base auf einen neuen Stand zu migrieren, bietet sich tatsächlich der Code-Freeze an. Das ist abhängig davon, ob man sich den Code-Freeze leisten kann, ob man Entwickler hat, die dafür motiviert sind, zu sagen: „Okay, wir machen von Scratch jetzt mal alles neu“. Der Vorteil davon ist, dass man nichts kaputt machen kann, denn man arbeitet dann nicht so am lebenden Objekt, sondern es ist ja gerade Code Freeze. Der Nachteil: zeitaufwendig und auch währenddessen, bis es live ist, je nach Größe, kann es dauern. Die zweite Variante, die dann vielleicht nicht so risikomäßig ist, ist zu sagen: „Wir wollen, dass alle Sachen, die wir neu schreiben, jetzt auf einer neuen Seite laufen, also quasi vielleicht sogar schon auf einem neuen URL, neuem Pfad, und wir bauen das relativ enkapsuliert. Das heißt, wir haben eine komplette Homepage, vielleicht mit einem Header und Footer, den wir noch als Grundgerüst drumherum bauen, aber alles, was da jetzt reinkommt, ist eine Vue Single Page Application, die dann in sich so komplex sein kann wie sie möchte. Ob das jetzt einen Riesenstore hat mit ganz, ganz vielen Submodules oder auch kleiner gehalten ist, ist nicht so wichtig, aber es gibt nur eine von diesen Vue-Applikationen auf dieser einen neuen Seite. Da gibt es die Lösungen, dass man natürlich dann auch mit dem API sprechen kann von seinem Server. Wenn man irgendwie etwas kommunizieren möchte oder irgendwelche Daten hin und her schicken möchte, wenn der User mit der Seite interagiert hat. Schwieriger wird es dann, wenn man Komponenten miteinander verbinden möchte – alte Komponenten und neue Komponenten, die aber irgendwie zusammen funktionieren müssen. Also, wenn ich jetzt ein JQuery-Teil habe und ich klicke hier darauf, dass ich es in dem Warenkorb hinzufügen möchte, und der Warenkorb ist in Vue geschrieben, dann muss es irgendwie dann zusammen funktionieren. Und Vue hat irgendeinen State Management, irgendeinen Store da liegen und JQuery macht das irgendwie anders oder bekommt seine Daten woanders her. Da gibt es jetzt verschiedene Möglichkeiten, die man in einem Team besprechen sollte, mit welchem man gehen möchte. Eine Möglichkeit ist, Custom Events zu verschicken, damit die beiden kommunizieren können. Andere Möglichkeit ist es – an das Window Object Daten dranzuhängen. Das sind alles lauter Sachen, die würde ich jetzt weder empfehlen oder auch nicht empfehlen. Man muss sich auch mal klar machen, man kann nicht eine Seite immer mal so schnell neuschreiben. Es gibt Zwischenlösungen, und wenn man die dann einfach step by step macht, dann funktioniert es eigentlich ganz gut.
Ann-Cathrin Klose: Da scheint aber stellenweise dann doch ein bisschen Aufwand dahinterzustecken. Wie ist es denn mit der Akzeptanz solcher Lösungen bei Unternehmen, die was an ihrer Webseite ändern möchten? Wie gut kommt der Vorschlag an: „Wir nehmen doch jetzt mal Vue“?
Vanessa Böhner: Das ist ganz unterschiedlich. Gerade in Europa ist Vue.js eigentlich relativ beliebt. Aus Gründen, die keiner so ganz genau weiß. Vielleicht, weil es nicht von einer großen Firma wie Google oder Facebook eben kommt oder einfach, weil es von einer Mannschaft kommt, so „Entwickler für Entwickler“. Und zuerst kam die Bewegung, dass Entwickler auf Vue.js aufgesprungen sind, und dann gab es diesen ganzen Hype drumherum. Das war alles so toll, da kam natürlich die Gegenbewegung: „Ja ist es jetzt wirklich so toll oder ist es mir jetzt alles zu gehypt und es ist alles zu gut um wahr zu sein? Dann, in letzter Zeit kann man auch auf Twitter verfolgen: Vue.js wird immer öfter eingesetzt und eigentlich niemand berichtet davon, von: „war eine schlechte Entscheidung“. Wie so ein kleines Lauffeuer verbreitet sich das gerade so, und wenn es schon ein Paar Proof of Concepts gibt: ja die haben es auch gemacht oder: eine große Firma hat es auch so gemacht, dann können wir es auch machen, alles in Ordnung.
Ann-Cathrin Klose: Genau, du hast aber gerade auch angesprochen, hinter Vue steht keine große Firma – nicht Google, nicht Facebook. Wie ist es denn mit der langfristigen Planbarkeit und Stabilität bei Vue?
Vanessa Böhner: Die Frage habe ich mir auch gestellt am Anfang, in den ersten zwei Jahren, in den ich mit Vue.js gearbeitet habe – das war noch die Vue-Version 2, die jetzt ja auch immer noch die aktuelle ist. Das war auch so, dass ich selber auch gesagt habe: „Ich weiß jetzt nicht, ob ich dieses Feature in Vue.js umsetzen würde, weil dieses Feature, das muss sicherlich über 10 Jahre laufen“. Und das muss, hat vielleicht eine wechselnde Mitarbeitermannschaft, die da dran entwickelt, seid ihr euch da sicher? Weil Vue.js-Entwickler gibt es jetzt noch nicht wie Sand am Meer. Angular und React sind mehr vertreten, also auch wenn ihr da ein Wechsel habt, vielleicht wäre das klüger? Und vor allem, was eben die Wartbarkeit von Vue.js angeht, vielleicht gibt es das Framework einfach in drei Jahren nicht mehr und dann müsst ihr auf Angular oder React oder was auch immer in fünf Jahren dann umstellen. Ich denke, vor ungefähr einem Jahr war für mich klar, Vue.js wird in der Zukunft bestehen bleiben. Als Vue 3 angekündigt wurde, das komplett auf TypeScript basiert, auf Analysen, Community, die es da mittlerweile gibt. Das ist keine One-Man-Show mehr, also die haben wirklich einem extrem guten Core an Entwicklern, die sich darum kümmern. Es gibt die Bestätigung, dass natürlich der IE 11 weiterhin supportet wird, und da sehe ich jetzt wirklich kein Problem mehr. Das ist etabliert.
Ann-Cathrin Klose: Also ist Vue eine spannende Option, wenn man auch ein älteres Projekt nochmal aktualisieren möchte?
Vanessa Böhner: Natürlich. Ganz klar!
